@microsoft-github-policy-service agree

Thanks for the PR!

This section of the codebase is owned by @saschanaz - if they write a comment saying "LGTM" then it will be merged.

I can't seem to get it to generate, I'm getting a ENOENT error. I don't have files in /inputfiles/mdn/

You need to have cloned the submodule as well.

git submodule update --init

This is blocked by #222 because vars can't be split by separate type declarations. We cannot just override the constructor because it'll break ES5 compatibility.

microsoft/TypeScript#3538 could greatly help without all those separate libs but I don't see that coming anytime soon.

ES5 is going to be deprecated, so maybe there's a future where it'd work out.

Thanks @jakebailey, got it to generate and committed the changes.

I am seeing the Cannot find name 'Iterable' error now during the test run, I assume this is the ES5 issue. Let me know if not!

Correct, but we're likely making DOM imply ES6 and DOM.Iterable in 6.0

But will 6.0 remove ES5 completely?

As a target for emit, yes, at least deprecated.

The rest is more a product of us wanting to make DOM.Iterable auto included, but that means we need Symbol, which means ES6, or at least the es6 symbol libs. It isn't really clean to do, so still figuring it out.

Actually, why isn't this being stuck into the iterable d.ts file?

I can add or feel free to edit as well! I'm not sure exactly which file you are referencing. Should it be added to the generated file here as the call signature? https://github.com/microsoft/TypeScript-DOM-lib-generator/blob/main/baselines/dom.iterable.generated.d.ts#L400

Actually, why isn't this being stuck into the iterable d.ts file?

Because we can't override constructors without having #222 first.

For 6.0, we're going to make the DOM types reference ES6/ES2015 (and promote DOM.Iterable to just being DOM), so we could probably just wait a bit and this will all be a non-issue.

Though, why isn't this a Constructor type instead of a named interface that can be merged into, like we do Map and such?

You mean defining a separate interface? Because that'll pollute the global namespace 2x than we do now...

Yes, since that's what we do in the main libs, but I suppose that would be pretty noisy.